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TECHNICAL FIELD 

The present invention relates generally to devices and methods for interacting with 
hypermedia servers connected to networks. More particularly, the present invention pertains to 
structures and methods of system interactions arranged such that practical access to hypermedia 
30 servers is available to a wider range of devices such as wireless telephones. 

BACKGROUND ART 

Although networks like the Internet have been in existence for years, they have not been a 
popular medium of information exchange until very recently. The recent explosive growth in usage 
35 of the Internet, for example, is due in large part to the development of devices and methods that 
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simplify the actions a user must take to access multimedia information stored by network servers. 
One significant development is the use of hyperlinks which allows disparate pieces of information 
to be organized in nonsequential ways and which allows a user to easily navigate among the linked 
informaiion. By assigning a unique identifier to each distinct piece of multimedia information 
5 available throughout a network, information can be readily accessed without regard to where ii is 
stored. Network clients and servers participating in such a "hypermedia" network are referred to 
herein as hypermedia clients and hypermedia servers, respectively. 

The Hypertext Transfer Protocol (HTTP) is one example of a method that implements 
hyperlinks and is probably the most widely used method for accessing the Internet today. A unique 
10 identifier, known as a Uniform Resource Locator (URL), specifies the location of a resource that 
can be accessed from the network. 

HTTP clients and HTTP servers typically communicate with one another using any one of a 
family of communication protocols known collectively as Transmission Control Protocol / Internet 
Jj Protocol (TCP/IP). One commonly used member of the family, known as Transmission Control 
1 5 UJ Protocol (TCP), provides for a very reliable delivery of an information stream. According to the 
TCP, a sender establishes a "connection" with a receiver, transmits an information stream in basic 
units known as packets, and retransmits any packets that are either lost or corrupted during 
p transmission. One advantage of the TCP is that it guarantees the receiver will receive the bits and 
p bvtes ~ m the information stream in the correct order. Unfortunately, the TCP requires considerable 
20 pj computing and network bandwidth resources. The establishment of a connection, for example, may 
require an exchange of more than ten packets between sender and receiver. 
2 In addition to the resources required to implement the TCP, the HTTP itself also requires 

considerable resources to format, process and display information. This is not a significant 
disadvantage in many situations because personal computers and other workstations with sufficient 
computing power, memory and display capabilities are readily available to implement the HTTP 
client function. 

There is, however, a growing interest to provide access to hypermedia servers connected to 
networks such as the Internet through mobile devices, particularly handheld devices like wireless 
telephones. These devices are characterized by severe limitations in processing power, memory 
space, display size, and buttons or keys by which a user can request, view and manipulate 
information obtained from a hypermedia server. Furthermore, the bandwidth of the communication 
channels connecting the mobile devices to the rest of the network is also severely limited. 
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A wireless telephone nas only a small fraction of the resources provided by a typical desktop 
or portable computer. Typically, the processing power is less than one percent of the processing 
power in many computers, the memory space is generally much less than 150 kilobytes (kB), and 
the display is perhaps four lines high and twelve or twenty characters wide. Graphics capabilities 
5 are very limited or nonexistent. The communication path is often in the range of 400 to 19,200 bits 
per sec. and the cost using that communication path is measured in terms of United States dollars 
per 100 kB or more. 

Attempts to implement HTTP client functions in portable devices have not been very 
successful. Attempts that have used mobile devices providing facilities which are comparable to 
10 conventional computers are unattractive because the cost of the device is very high. Other attempts 
using less expensive devices are also unattractive because the client functions are severely limited. 
In either case, the communication delays and costs in exchanging packets with the network just to 
establish a connection, for example, are intolerable. The delays are particularly annoying in 
I Situations where a user is notified that electronic mail or other information has been received in the 
1 5 jjrj user's "mail box" somewhere on the network and the user must wait during the roundtrip delay 
W required to request Md receive ™U fr°ni the mail box. The usability of the device is further 
| impaired because there is insufficient memory space to store lists of frequently used hyperlinks. For 
ft RTT * ° licntS ' **** hv P e 'Iink identifiers are URLs that are often difficult to remember and difficult 
• Q to enter into the device due to limited date entry capabilities. Two popular software products used in 
conventional computers refer to these stored hyperlinks as "bookmarks" and "favorites." 



jj DISCLOSURE OF INVENTION 

It is an object of the present invention to provide structures and methods required by devices 
to interact with hypermedia servers connected to networks so that practical access to such servers is 
25 available to a wider range of devices such as wireless telephones. 

According to the teachings of the present invention in one embodiment of a system that 
comprises a remote device coupled to a directory server, the remote device is remotely located with 
respect to the directory server, comprises first storage, a display and a button, and executes a first 
program that causes the remote device to receive a unit of information from a hypermedia network, 
30 the unit of information having an identifier, and to present on the display a representation of the unit 
of information, to receive an input signal in response to the button being activated and, in response, 
to send an add request to the directory server that conveys the identifier, and the directory server 
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comprises second storage uiat stores a directory associated with the remote device and executes a 
second program that causes the directory server to receive the add request and, in response, to add 
an entry to the directory representing the identifier. 

The various features of the present invention and its preferred embodiments may be better 
understood by referring to the following discussion and the accompanying drawing. The contents of 
the following discussion and the drawing are set forth as examples only and should not be 
understood to represent limitations upon the scope of the present invention. 

BRIEF DESCRIPTION OF DRAWING 

The Figure illustrates in schematic form the major components of a system in which a 
device such as a wireless telephone can access the resources provided by a hypermedia server 
connected to a network. 



MODES FOR CARRYING OUT THE INVENTION 



1§1 Overview 

The Figure illustrates a system in which various aspects of the present invention may be 



Ml practiced. As will be explained below, some of the components illustrated in the Figure may be 
grj omitted in various embodiments. As shown, client 1 uses network 40 to access resources provided 
by server 5 1 and server 52. Although it is contemplated that server 5 1 and server 52 are hypermedia 
2gj servers, perhaps operating in conformity with the Hypertext Transfer Protocol (HTTP) this is not 
*p necessary to practice the present invention. 

£j Client 1 comprises computer 3 1 and device 11 ^ which is remotely located with respect to 

computer 3 1 . Remote device 1 1 and computer 3 1 perform functions that implement client 1 . 

Remote device 1 1 provides a user interface through which information can be presented to a user 
25 and input can be received from a user. Computer 3 1 exchanges information with network 40 in a 

manner that is consistent with a conventional network client. 

Computer 3 1 stores parameters and information in storage 32 that typically is a combination 

of random access memory (RAM), read-only memory (ROM) and long-term storage devices such 

as magnetic and optical disk drives. Computer 31 communicates with remote device 1 1 through 
30 receiver 21 and transmitter 22. Information that is sent by computer 3 1 through transmitter 22 is 

received by remote device 1 1 through receiver 16. Information that is sent by remote device 1 1 

through transmitter 15 is received by computer 31 through receiver 21. 
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In the embodiment s ,iown in the Figure, remote device 1 1 comprises display 12, one or 
more buttons 13, storage 14, transmitter 15 and receiver 16. For example, device 11 may be a 
wireless telephone such as a MobileAccess™ telephone by Mitsubishi Wireless Communications, 
Inc., or a Duette telephone by Samsung Electronics Corporation. In typical wireless telephones, the 
5 display 12 is a liquid crystal display (LCD) panel. Buttons 13 represent one or more data entry' 
devices such as switches, keys or buttons. Storage 14 represents memory circuits or other devices 
that are capable of storing digital information. Preferably, at least part of storage 14 is persistent 
storage, meaning that information is retained when device 1 1 js turned off. In some embodiments, a 
portion of storage 14 is organized into a unified push/pull cache. It is also contemplated that a 
portion of storage 14 will store program instructions, either in persistent memory or in ROM, and 
that device 1 1 will comprise a microprocessor or other type of processing circuitry capable of 
executing the program instructions. 

The nature of the communication paths shown between computer 3 1 , server 5 1 server 52, 
S reCeiver 21 * nd transmitter 22 a" critical to the practice of the present invention. Such paths 
may be implemented as switched and/or non-switched paths using private and/or public facilities. 
Jy Similarly, the topology of network 40 is not critical and may be implemented in a variety of ways 
including hierarchical and peer-to-peer networks. Computer 31 and server 51, for example, may be 
locally located with respect to one another and may be implemented on the same hardware. 
q In concept, the nature of the communication paths between computer 3 1 and device 1 1 is 

20| also not critical to the practice of the present invention; however, in many applications device 1 1 is 
a wireless device that uses a communication technology such as electro-magnetic transmission in 
the radio-frequency to infrared portions of the spectrum. In applications where device 11 is a 
wireless telephone, a cellular telephone for example, transmitter 15, receiver 16, receiver 21 and 
transmitter 22 represent communication facilities used for normal telephone calls. 
25 Examples of devices and methods that may be used to practice various aspects of the present 

invention are discussed below. The following discussion describes variations of a preferred 
embodiment that implements client 1 according to the HTTP; however, it should be understood that 
the present invention is not so limited. 

Remote Device 

In applications where client 1 is implemented as a HTTP client, device 1 1 provides at least 
three basic functions. A navigation function allows a user to navigate or traverse HTTP Uniform 
Resource Locator (URL) hyperlinks. A communication function exchanges information with 
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computer 3 1 . An interface runction provides a user interface through which information may be 
presented to the user and through which input may be received from the user. 

Preferably, these functions are implemented by a software-controlled process using an 
event-driven architecture. Events may be initiated by a user through buttons 13, for example, or 
5 may be initiated by signals received through receiver 16. The navigation function operates in either 
of two states. In the "ready" state the device awaits user input specifying a hyperlink to traverse. In 
the "pending" state the communication function has submitted a request to computer 31 and the 
device is waiting for a reply from computer 3 1. In terms of the HTTP, the ready state waits for user 
input specifying the URL of a hypermedia entity to display or process and the pending state waits 
10 for computer 3 1 to provide a requested hypermedia entity. 

In one embodiment, hypermedia information is exchanged with computer 31 according to 
the Handheld Device Transfer Protocol (HDTP). A specification for a version of this protocol, 
sometimes referred to as Secure UPLink Gateway Protocol (SUGP), is provided in an Annex. The 
O HDTP resembles the HTTP but is optimized for use with remote devices like wireless telephones 
1 5 U1 ^ preferably is conveyed using the User Datagram Protocol/IP (UDP/IP). The UDP/1P is 
jjj generally regarded as being less reliable than TCP/IP, for example, because it does not guarantee 
m that packets will be received, nor does it guarantee that packets will be received in the same order 
Jj that they are sent. Datagram protocols like the UDP/IP are attractive in practicing the present 
^ invention, however, because it does not require a "connection" to be established between a sender 
20 jjj and a receiver before information can be exchanged. This eliminates the need to exchange a large 
JjjJ number of packets during session creation. 

SQ In a preferred embodiment, hypermedia information is organized according to a Handheld 

** Device Markup Language (HDML) into cards and decks. Multiple decks and other types of 
message entities can be organized into information structures called digests. A specification for a 
25 version of HDML is provided in the Annex. 

A "deck" is the smallest unit of HDML information that can be exchanged with computer 
3 1 Each deck has a unique identifier or URL. A user may navigate from one deck to another by 
traversing hyperlinks that reference the desired deck. If remote device 1 1 has a cache for received 
decks, the device first consults the cache to determine if the requested deck is available. Remote 
30 device 1 1 may also be implemented to determine if a desired deck found in cache is also current, 
that is, not out of date. If so, that deck is accessed without requiring any communication with 
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computer 3 1 If the requested deck is not in the cache or is out of date, however, a request for that 
deck is sent to computer 31. This is discussed in more detail below. 

Because the display on remote device may be too small to show all the information in a deck 
at one time, each deck may be organized into one or more cards. A "card" is a unit of information 
5 that can be displayed and/or can define how a user may interact with the device. 

There are several types of cards. A "display" card conveys information that is to be 
displayed. An "entry" card conveys a method that permits a user to enter information and typically 
also conveys information to display. A "choice" card presents alternatives for selection by a user. 
Entry and choice cards also convey methods to be performed by device 1 1 that cany out functions 
10 necessary to receive input or recognize the chosen alternative. Typically, entry and choice cards 
cause one or more state variables to be set according to the information that is entered or the 
alternative that is chosen. A display card can also set one or more variables. A special form of the 
^ display card does not cause any visible display but can be used to set one or more variables. 
J A " di S est " is 311 optional information structure that may be used to facilitate the transmission 

1 ill and processing of multiple message entities including HDML decks. In particular, each message 
y entity in a digest is processed in sequence according to entity type. In one embodiment, message 
Jjj entity rypes include HDML decks, images and alerts. One important use of the digest and the alert 
Q1 entity is discussed below. 

q The current state of the three basic functions, navigation, communication and interface, can 

be expressed in terms of the deck and card in that deck that is currently displayed and one or more 
variables needed to process the card. By saving this information in persistent storage, remote device 
1 1 can restore the current state at a future time. A cache of decks, a navigation history of hyperlink 
traversals and a history of user activity can also be used to improve performance, provide additional 
functions to the user, and provide additional facilities for use by system developers. 

Handheld devices like telephones have severely limited facilities for entering information. 
The input facilities of these devices are often limited to the familiar twelve keys of a pushbutton 
telephone. One common method for entering text is to assign letters to various numeric keys 
according to normal telephone conventions. For example, the letters ABC are assigned to the "2" 
key and the letters DEF are assigned to the "3" key. The letters Q and Z could be assigned to the "0" 
key, for example. According to this method, the letter A is entered by pressing the "2" key once and 
the letter B is entered by pressing the key twice. In preferred embodiments of remote device 1 1, a 
form of letter prediction is used to make text entry more efficient. 
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This prediction can ce based on the statistics of letter combinations. For example, after 
entering the letters T and H, it is much more likely that a user will enter the letter E than the letters 
D or F. Accordingly, after entering T and H, in response to a user pressing the "3" key, remote 
device 1 1 will present the letter E first rather than the letter D. The prediction can be based on a 
table of probabilities for various three-letter combinations stored in storage 14. 

Intermediate Computer 
Computer 31, together with remote device 1 1, provides the functions of a conventional 
hypermedia client. In the embodiment discussed above, computer 3 1 receives information from 
remote device 1 1 according to the HDTP, translates the HDTP information into corresponding 
HTTP information as necessary, and sends the result to server 51. Similarly, computer 31 receives 
information from server 5 1 according to the HTTP, translates the HTTP information into 
corresponding HDTP information as necessary, and sends the result to remote device 11. 
Preferably, HDTP information exchanged with remote device 1 1 is compiled from a textual form 
into a binary form that reduces the bandwidth requirements of the communication channel and 
reduces the processing required by remote device 1 1 to parse and interpret the information, 
y Alternatively or in addition, the information may be subjected to other types of data compression to 
^ reduce bandwidth requirements. 

Basic Exchange of Messages 
By using the UDP/IP, a session can be created more efficiently than is possible using the 
more common TCP/IP. The exchange of information needed to create a session is similar to the 
exchange carried out for other types of requests. An exchange can be initiated by remote device 1 1 
sending a request to computer 3 1 . Subsequently, computer 3 1 returns a reply to the request and 
remote device 1 1 acknowledges receipt of the reply. The reply may either be expected results of the 
request or it may be an indication of some error encountered while attempting to service the request. 
If remote device 1 1 does not receive a reply within some timeout interval, it will send the request to 
computer 3 1 again. Remote device 1 1 will send the request repeatedly until either it receives a reply 
message, or a standby or "HoldOn" message from computer 3 1 . The length of the timeout interval 
can be user configurable or it can be established by information previously received from computer 
3 1. Similarly, computer 3 1 will send the reply repeatedly until it receives the acknowledgement 
30 from remote device 1 1. 

For example, remote device 1 1 may initiate the creation of a session by sending a session- 
creation request to computer 31. The request includes any necessary authentication information, one 
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or more session parameter., and information describing the device and version of software in use. 
Computer 3 1 receives the request, validates the authentication information, checks that the user is 
entitled to initiate a session, assigns an identifier to the new session, builds a message containing 
the session identifier and any information that computer 3 1 wishes to pass to remote device 1 1, and 
5 sends the message to remote device 1 1 Preferably, this message also includes the URL of a "home 
page" associated with the device. Remote device 1 1 acknowledges receipt of the message and the 
session is established. 

Get Request 

As another example, when a user traverses a hyperlink, remote device 1 1 consults its cache, 
10 if any, and determines if the cache already has the requested hypermedia entity (HDTP deck). If it 
does and the deck in the cache is not out of date, remote device 1 1 can process the requested deck 
and no further action is required. If the requested deck is not available or is out of date, however, 
remote device 1 1 builds a message including a HDTP "Service Request" and the URL of the 
requested deck and sends the message to computer 31. According to the HDTP, the message also 
15 uj includes a header with information that is unique to the request. Remote device 11 then waits for a 
reply from computer 3 1. The reply may be the requested deck or it may be an indication that an 
error occurred while attempting to service the request. 

Computer 3 1 receives the request, checks its validity and attempts to establish a connection 
jL with the appropriate network server, say server 5 1 . If the connection fails, remote device 1 1 is 
20 jjj notified. Otherwise, computer 3 1 builds a message that includes a HTTP "GET" method and the 
J URL of the desired hypermedia entity. In one embodiment, the header of the message is constructed 
| from "common" parameters that are common to all users, from "session" parameters that are unique 
to the session with remote device 1 1, and any "request" parameters that were passed in the header 
of the HDTP request. Preferably, any conflicts in the three sets of parameters are resolved in favor 
25 of request parameters first, session parameters second, and common parameters last. Alternatively, 
the HTTP header may be constructed from just common parameters, just session parameters, just 
request parameters, or any combination of these parameters. 

After constructing the HTTP get request, computer 3 1 sends it through the established 
connection to server 51. Server 51 attempts to service the HTTP "GET" request and sends the result 
30 to computer 3 1 in a HTTP response. Computer 3 1 checks a result code contained in the header of 
the HTTP response. If the result code indicates an error occurred, computer 3 1 may take any of 
several possible actions explained below. If the result code indicates the request was serviced 
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successfully, computer 3 1 uuilds an appropriate HDTP response containing the results of the get 
request and sends the HDTP response to remote device 1 1 . Computer 3 1 may compress, encrypt or 
convert the result as desired. If server 51 does not respond with a complete result within a 
reasonable period of time, the connection is dropped and an error indication is returned to remote 
5 device ] 1. 

Remote device 1 1 acknowledges receipt of the HDTP response and displays and/or 
processes message entities included in the response. If computer 3 1 does not receive an 
acknowledgement within a reasonable period of time, it sends the HDTP response again. Computer 
3 1 may repeat the transmission one or more times until an acknowledgment is received. If an 
acknowledgement is not received after a desired number of attempts, computer 31 may discard the 
result and abandon the attempt to send it, save the result in storage 32 for a future attempt, or save a 
message for future transmission indicating the result was discarded. 

Variations on the Get Request 
Computer 31 may respond with error indications for a variety of circumstances. For 
1 5Jl example, computer 3 1 may notify remote device 1 1 that the requested URL is for a scheme or 

protocol that is not supported, or that the requested URL designates a network server that cannot be 
resolved using the Domain Name Service (DNS). 

HTTP result codes are numerical codes of the form XXX. If the result code in a HTTP 
Q res P OQ se is 301 or 302, a "redirection error," it indicates the requested resource has been moved. 
m The new URL may be returned to remote device 1 1 . Alternatively, computer 3 1 may respond to the 
^ redirection error by using the new URL to establish a connection with the new server say server 52 
g construct a new HTTP get request and submit it to server 52. The response from server 52 and the 
new URL are returned to remote device 1 1. 

If the result code in a HTTP response is 401, it indicates the user is not authorized access to 
25 a particular "realm." Computer 3 1 may check storage 32 to determine if there is a user name and 
password for the realm that generated the error. If an appropriate user name and password are 
available, computer 3 1 can resubmit the request with the authorizing information. If a user name 
and password are nor available, or if the resubmitted request results in a another unauthorized error, 
computer 3 1 may construct a HDTP deck with an entry card by which the user can enter the correct 
30 user name and password for the realm generating the error. 
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Generally, client ewors (4xx), server errors (5xx) and other types of errors may be handled 
by computer 3 1 returning a deck with one or more display cards explaining the nature of the error 
and what course of action the user may consider taking. 

Additional Functions and Features 
Remote device 1 1 can use a post request to send data to a server. In one embodiment, 
remote device 1 1 builds a HDTP "Post" request including the URL of the intended network server 
and a block of data. Computer 3 1 constructs and sends a corresponding HTTP "POST" method in a 
manner similar to that described above for the get request. 

Although many client functions do not need to be implemented to realize the benefits of the 
present invention, some client functions are important in many applications. These functions 
include creating and managing sessions with a hypermedia server, handling a variety of error 
conditions like those discussed above, authenticating a user to the server, establishing a private 
session and managing user certificates and encryption keys, managing a first level cache, handling 
J redirection errors and validating hypermedia content. 
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The operational characteristics of client 1 are affected by parameters and other information 
£jj stored in storage 32. Examples of operational characteristics include a list of authorized subscribers 
Jjj or users, resources that are available to each respective user, and timeout values for respective 
m remote devices 1 1 and computer 3 1 . In preferred embodiments, these parameters and information 
O "* maintained by a facility on computer 3 1 that operates as a network server, perhaps a HTTP 
20 fU server. In this manner, the operational characteristics of client 1 can be administered locally or 
remotely by an authorized network client. 

The headers for each HTTP request can include a parameter that specifies what type of 
content for the response is acceptable. As mentioned above, in some embodiments this parameter 
can be obtained from common parameters, session parameters or request parameters. Computer 3 1 
25 can check the content of any reply from a server and determine whether the content is acceptable to 
remote device 1 1 If the content is not acceptable, computer 3 1 may notify remote device 1 1 of the 
error. For example, content types such as applets, movies and certain types of images may not be 
acceptable. Alternatively, when possible, computer 31 may convert the content into a form that is 
acceptable. For example, computer 3 1 may be able to convert one type of image, say JPEG, into an 
30 acceptable form, say GIF. 
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Remote Device Initialization 
An HDTP session can have a very long life, extending beyond the time remote device 1 1 is 
turned off. A session can also be interrupted by some other function remote device 1 1 i 5 required to 
perform such as, for example, a wireless telephone initiating or receiving a voice telephone call. 
5 Remote device 1 1 can resume a suspended session with computer 3 1 by preserving session-related 
information in persistent storage. This information includes the session identifier and any 
information required to identify computer 31. In addition, if encryption has been in use for this 
session, the saved information can include encryption keys, flags indicating the type of encryption 
method, block-chaining values, or other information needed to resume encryption. Alternatively, 
encryption can be initiated anew as is done at time of session creation. 

Li an embodiment allowing resumption of a suspended session, remote device 11, when 
turned on, determines whether a session was suspended. If it was, remote device 1 1 sends a request 
to computer 3 1 using the session-related information stored in persistent storage. Computer 3 1 
receives the request, validates the session and determines whether the session has expired. If the 
15jjj session is valid, computer 3 1 services the request. If the session is not valid, computer 31 returns an 
error indication to remote device 1 1 which can then initiate a request to create a new session. 

At the time of session creation, remote device 11 establishes session parameters used to 
construct HDTP headers. These parameters can be set according to values provided by remote 
device 1 1 and/or computer 31. These parameters may include HTTP related values such as Accept, 
Accept-Charset and Accept-Language, and they may include values not related to the HTTP such as 
a timeout interval between sending retries, maximum packet length remote device 1 1 can accept 
and the encryption algorithm to use. Preferably, in subsequent exchanges between remote device 1 1 
and computer 3 1 after these parameters are established, headers include only parameters that the 
receiving device does not already know. 

Preferably, headers are formed in a manner that simplifies the processing required to parse 
and interpret the embedded information. Headers for the HDTP contain pairs of ASCII text strings, 
each string terminated by a null or zero-valued byte. The first string in each pair specifies a key or 
parameter name and the second string provides the key's value. Most headers contain a single byte 
that specifies the header type. Frequently used keys and values can be encoded into single bytes 
30 having a value from 128 to 255. 
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In preferred embedments, remote device 1 1 also checks during initialization for anything 
relevant that is pending in computer 3 1 . For example, responses or message entities may have 
queued up in computer 3 1 while the session with remote device 1 1 was suspended. 

Most practical implementations of remote device 1 1 do not maintain accurate time. In 
preferred embodiments, during initialization or at any time thereafter, remote device 1 1 can obtain 
the current time from computer 3 1 by a request. 

Reducing Perceived Latency 
Various network services including electronic mail have the ability to notify a user when 
some asynchronous or unsolicited event has occurred or is about to occur. In this context, the term 
"unsolicited" refers to an event that is not a direct result of some user request. A notification of the 
arrival of one or more pieces of electronic mail or data from other users or from services providing 
periodic stock price quotations are examples of unsolicited events. In response to the notification, a 
user can request delivery of the mail, the data, or some other message from the network server that 
^ provided the notification. Referring to the Figure, the network service providing the notification 
im may reside on server 5 1, for example, or it may reside on computer 3 1. 
y The time required to obtain the unsolicited information is at least as great as the total time it 

takes to convey the request to the server and to convey the reply from the server to the user's 
terminal or workstation. In conventional systems, the communication time is usually not a factor; 
however, as mentioned above, signal propagation time between remote device 1 1 and computer 3 1 
can be significant in systems where the communication path has a low bandwidth. For example, 
data communication via wireless telephones is sometimes restricted to as little as a few hundred bits 
per sec. 

Significantly, the primary source of user dissatisfaction in such applications is how much 
time is spent waiting for return of the reply, not when the reply actually arrives. For example, if 
electronic mail were to arrive in a user mail box at 3:00 p.m., most users would not be concerned 
whether the mail reached their terminal at 3;02 p.m. or 3:05 p.m. What is of concern, however, is 
the perceived delay, the time spent waiting for requested information to arrive. The perceived delay 
can be greatly reduced by delivering at least a portion of the unsolicited information to remote 
device 1 1 before notifying the user. 

In one embodiment, a network service receives messages representing one or more instances 
of unsolicited information for remote device 11. That network service causes computer 3 1 to 
generate one or more message entities representing at least a portion of the unsolicited information 
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and to send those message entities to remote device 11. Preferably, the message entities are 
assembled into one or more HDML decks that are contained in a digest. Also included in the digest 
is a message entity that specifies an operation, or type of operation, that remote device 1 1 i s to 
perform to notify the user. The notification may be a visual presentation on screen 12, or it may be 
an aural or tactile presentation by some other suitable transducer. The notification may also be 
accompanied by text, presented on display 12, explaining the nature of the notification. The 
message entity specifying the notification can also contain the URL of any related hypermedia 
entity such as the fulltext of electronic mail, embedded files, an "entry" card for preparing an 
immediate reply, etc. 

In electronic mail applications, the digest preferably includes cards representing a portion of 
each piece of mail, say the first 100 characters, one or more cards containing a list of all mail in the 
user's mail box, and a card with one or more URLs that causes the network service to deliver the 
text of one or more messages. Remote device 1 1 should process the cards, decks and other message 
entities included in the digest in strict order. Significantly, the notification or alert message entity 
15UJ should be processed after the preceding message entities have been stored in storage 14 and are 
UJ ava ilable for display or other processing. 

In practice, notification or alert message entities are often used with "prefetch notifications." 
Prefetch notifications specify a deck or digest which an application executing in remote device 1 1 
requests and stores in storage 14 before notifying a user. 

In preferred embodiments of remote device 1 1, notification or alert message entities are 
stored in persistent storage and a card is provided that displays a list of alert message entities that 
have been sent to remote device 1 1. An indication of whether a user has acted on a notification is 
stored and displayed for each respective alert message entity. When a new alert message entity 
arrives, remote device 11 determines if a duplicate emity is already stored. If a duplicate entity is 
stored, the older entity is deleted and the new entity is stored, clearing any indication that the user 
has acted on the corresponding notification. 

Saving Lists of Bookmarks 
In devices like wireless telephones, there is usually insufficient storage to save lists of 
frequently used hypermedia links, e.g., URLs. This limitation reduces the usefulness of these 
devices because hypermedia links are usually difficult to remember and especially difficult to enter 
into the device. Software products for conventional computers provide facilities to save lists of 
these links. Two popular products refer to these stored links as "bookmarks" and "favorites." 
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This limitation is overcome by storing designated hypermedia links or bookmarks on a 
network server, referred to herein as a bookmark server. In one embodiment, the URL of this server 
is sent to remote device 1 1 during initialization of the device. 

In response to the activation of a particular button 13, remote device 1 1 uses the bookmark 
5 server URL to construct a request to save the bookmark of the deck containing the currently 
displayed card. This may be done by appending the bookmark server URL with an argument 
specifying the deck bookmark and submitting the request to computer 3 1 . Computer 3 1 passes the 
request to the bookmark server. The bookmark server services the request by saving the bookmark 
specified in the argument in a list uniquely associated with remote device 1 1 . I n addition, an entry 
card can be used to prompt the user for a name or description of the bookmark. The name and 
bookmark URL are sent to the bookmark server which saves the bookmark and accompanying 
name in the list. Preferably, the bookmark server can also store one or more state variables used by 
remote device 1 1 to display or process the associated deck. For example, a state variable may be 
used to save information that a user entered through an entry card. These state variables can be 
15jfl conveyed to the bookmark server by additional arguments appended to the server URL. 
J3 In preferred embodiments, decks and specified cards within decks may contain indications 

that they cannot be bookmarked. If a user attempts to save a bookmark for such a card or for any 
card with such a deck, remote device 1 1 is caused to display an appropriate message informing the 
user that the current card cannot be marked. 
20 gj Remote device 1 1 can request all or part of the stored list by sending an appropriate request 

| to the bookmark server. In one embodiment, the request comprises the URL of the bookmark server 
I appended with an argument specifying the first entry in the list to send. For example, an initial 
request would specify the first entry in the list. In reply, the bookmark server would build a 
response representing entries one through N and a value referencing entry number N+l . A 
25 subsequent retrieval request from remote device 1 1 would include the URL of the bookmark server 
appended with an argument specifying the N+l entry. By continuing in this manner, the user is able 
to retrieve and display all entries in the stored list of bookmarks. 

The deck and cards in the reply received from the bookmark server can also contain 
methods for modifying or deleting bookmarks in the stored list. A request to modify a bookmark 
can be made by appending the bookmark server URL with arguments specifying a change to the 
selected bookmark and the desired change. Similarly, a request to delete a bookmark can be made 
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by appending the bookma, . server URL with arguments specifying a deletion of the selected 
bookmark. 

By implementing the bookmark server as a standard HTTP server, the bookmark list for a 
user can be accessed and maintained by any standard HTTP client. This feature allows a user to 
5 setup and maintain the list more easily using a conventional computer. 

Annex and Incorporated Documents 
Documents in an Annex to this main disclosure, computer listings in the microfiche 
appendix, and documents incorporated herein by reference, include specifications, proposals, 
specific implementations and features of particular products that describe and embody various 
aspects of the present invention. Terms such as "required," "must," "significant,- "necessary," 
"minimum" and "maximum" refer to particular embodiments disclosed therein and do not represent 
limitations on the scope of the present invention. Because these documents describe several 
versions of specific products, specifications and proposals, some features and terminology may 
differ among the several documents and this main disclosure. Not all features described therein are 
1 SJi required to practice the present invention; the various features may be used in essentially any 
jj combination. These documents describe some features that are either omitted or are not discussed in 
as much detail in this main disclosure. To this extent, these documents augment the main 
disclosure. To the extent that these documents disclose or suggest limitations that are not described 
in the main disclosure, those inconsistencies are to be resolved in favor of the main disclosure. 
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